After a week off, we return with the second part of Geoff's detailed look at the PowerPC chip and other bits of Macintosh architecture. Adam weighs in with advice for people who have to give Internet presentations, and Tonya looks at a couple of Web browser plug-ins that help browsers both talk and listen, along with a new mailing list called Disabled-Talk. MailBITS about the release of the commercial System 7.5.3 and BBEdit 4.0.1 round out the issue.
This issue of TidBITS sponsored in part by:
Apple's Call for Unity -- Apple has finally released the long-awaited retail version of System 7.5.3. This version can install a universal system that will boot anything from a Mac Plus onwards. Codenamed Unity, the retail version of System 7.5.3 includes the fixes from System 7.5.3 Revision 2 (see TidBITS-332), LaserWriter 8.3.4 (see TidBITS-333), support for 8x CD-ROM drives, the Apple Internet Connection Kit, and an optional installer for OpenDoc 1.0.4. The software costs $99 and should be available shortly through the usual retail software channels on floppy disk or CD-ROM; current System 7.5 owners can upgrade for $49 by calling 800/293-6617, ext. 1 with proof of ownership. For many Mac users and support personnel, installing System 7.5.3 required running through an involved series of installers, downloads, and patches - it's nice that Apple finally put everything together in a single release, even if it will soon be eclipsed by new versions of Open Transport and other system components. Apple says international versions of Unity should be available in the next 90 days. [GD]
<http://product.info.apple.com/pr/press.releases/1996/q4/960702.pr.rel.macos.html>
BBEdit 4.0.1 Update -- Bare Bones Software released an update to BBEdit 4.0.1, which includes improved HTML tools, the ability to edit and store text files on an FTP server directly, and (notably!) multiple undos. The update is free to existing BBEdit 4.0 customers; the update does not work with any version of BBEdit Lite. [GD]
<ftp://ftp.barebones.com/pub/updaters/>
by Tonya Engst <tonya@tidbits.com>
Interested in interfacing with the Web using sound? Two browser plug-ins, ListenUp and Talker, enable you to do just that. I've used both plug-ins without crashes in both Netscape Navigator 2 and Internet Explorer 2 on my Power Macintosh 7100. Both plug-ins require that you install PlainTalk, Apple's speech recognition technology, which comes with Apple's System 7.5 and can also be downloaded from various online venues.
Written by Bill Noon, ListenUp 1.41 enables you to follow links by speaking their names. There are a few catches: you must have a Power Mac equipped with a PlainTalk microphone, run System 7.5 or newer, and be following a link on a Web page specially coded to work with ListenUp. In addition, you must be lucky enough to have voice recognition usually work for you; I've only had moderate success in this department. Web authors who wish to support ListenUp must include a short bit of additional HTML on their pages (for those in the know, that short bit is an <EMBED> tag), and they must also place on their Web servers a text file that associates link text with URLs.
<http://snow.cit.cornell.edu/noon/ListenUp.html>
In contrast to ListenUp, which helps Web browsers listen, Talker 2.0 makes Web browsers talk. The free plug-in from MVP Solutions lets you hear the text displayed on Web page. A Talker-enabled Web page displays onscreen in the normal, visual fashion, but your Mac automatically speaks the words on the page. Web authors can even set up pages such that different bits of text are spoken, or even sung, in different voices. To use Talker, you must have the English Text-to-Speech component of PlainTalk installed. The Talker Read Me file helpfully discusses how to tell if you have the right software installed, and what to do if you don't.
<http://www.mvpsolutions.com/PlugInSite/Talker.html>
TidBITS doesn't currently support ListenUp- or Talker-savvy HTML, but I wouldn't rule it out for future issues. However, instead of HTML authors adding special HTML tags to enable their pages for speech, it would be nice to see more browsers support speech. For instance, NCSA Mosaic 3.0b2 can speak the contents of pages without requiring special HTML. A sufficiently savvy browser might even have mannerisms like emphasizing text in <EM> tags or letting you configure what voices speak when your Macintosh reads differently tagged text. For instance, you might assign headings a more authoritative voice than regular body text.
<http://www.ncsa.uiuc.edu/SDG/Software/MacMosaic/>
One TidBITS reader already uses PlainTalk and his PowerBook during his daily commute in order to keep up with TidBITS and other online periodicals. He's not a Mosaic user, so it takes some setting up on his part, but apparently the time it takes to drive from his home in Redmond to his office in downtown Seattle is just long enough to listen to a complete TidBITS issue.
Disabled-Talk -- If your interest in interfacing with the Web via sound has less to do with novelty and more with necessity, or if you are generally interested in additional methods of interacting with and using a Macintosh, you might wish to join the new Disabled-Talk mailing list. The list's charter calls for discussions to center on Mac-related techniques and technologies that make life easier for people having disabilities or handicaps. Such discussions might include information about using sound to interface with a Macintosh, screen magnification, and using a Mac to automate a variety of tasks, such as turning on lights.
<http://thelorax.res.cmu.edu/lists/disabled.html>
by Adam C. Engst <ace@tidbits.com>
I've been giving a number of talks recently at conferences like the Adobe Internet Solutions Conference, and I thought I'd share some of the tricks and techniques that I've worked up for Internet presentations.
While I was a student at Cornell, my part time job involved managing a seminar room with a projector. I've seen (and rescued) far too many demonstrations undermined by technical glitches. As a result, I tend toward extremely low-tech presentations. Short of laryngitis, there's not much that can go wrong if you're just talking. Add an overhead projector and the bulb could blow; use a Macintosh and the projector can mess things up in any number of ways, not to mention all the potential problems of using an unfamiliar Mac with unexpected fonts and extensions. Add a live Internet connection and you're tempting the laws of Murphy (whatever can go wrong, will).
So, my main advice for any presentation is to keep the level of technology involved to a minimum. Obviously, since we're talking about Internet presentations, that's difficult, so the corollary is that when you must do a high-tech presentation, isolate and eliminate as many variables as possible. If you have your own PowerBook and can connect to the projector, use your PowerBook rather than whatever Macintosh might already be there. If you have your own modem, ditto. Anything you can do to stick with a known, working situation rather than venturing into the unknown reduces your chances of blowing the presentation.
For Internet presentations these days, I've had extremely good luck with doing my "slides" in HTML rather than in a program like Persuasion or PowerPoint. Aside from the fact that I don't use either of those programs, HTML is extremely flexible. For instance, I can put my presentation up on my Web server as a backup in case something happens to the copy I bring with me. I've never needed that backup, but making slides in HTML also simplifies showing off a variety of Web sites as part of the presentation - just click and you're there. I've made HTML slides for presentations a few times now, and they tend to be extremely simple. Each slide usually contains a small graphic at the top and then a short list of points. The slide finishes with Next and Previous links for moving around. You can make links all over in your presentation, but I recommend keeping it mostly linear because it's too easy to become flustered while you're on stage.
The way I create my slides is a little unusual. Working from an outline, I go straight through the talk, creating the HTML file for each slide as I go. I name the first file something like "connect1.html" and when I'm done with that one, I duplicate it in the Finder, rename it to "connect2.html" and edit it, which is easier and more consistent than trying to do each one from scratch. Get the first one right, or else you'll have to make changes in all the files after that point. Small changes aren't a problem if you use a tool like BBEdit or NisusWriter that can find and replace across all the files in a presentation. I've seen other HTML slide presentations done as a single long HTML document, which you can either scroll through or use internal anchor links.
If you plan to show examples of Web sites during your presentation, consider using WebWhacker from The ForeFront Group to download some of the site, complete with graphics and internal links. That way, if your Internet connection isn't working when you give the presentation, it won't matter. It's often a good idea to make two links for each sample site, a local one to the downloaded version of the site and a remote one to the online version of the site, because there are times that you might not have downloaded the part of the site you need. More importantly, sometimes it's good to show the real speed of the site, rather than the speedy canned demonstration from your hard disk.
<http://www.ffg.com/whacker.html>
Another reason to use HTML for your presentation is that it provides a variety of options for which browser you use. Unless you present sites that rely on Netscape extensions, for instance, it doesn't matter all that much. Tonya likes using MacWeb because it provides much more control over onscreen fonts and styles than Internet Explorer or Netscape Navigator. Speaking of fonts, when you test your HTML at the site of the presentation with the projector on, make sure the font you use is readable from the back of the room. Netscape, for instance, defaults to using Times 12 point for its text font, which is small and hard to read onscreen. I usually switch to New York 12 point, which is easier on the eyes and designed for onscreen readability. If you use separate HTML files for each slide, run through your entire presentation to ensure you'll have a minimum of scrolling - scrolling distracts you from the task at hand, which is speaking.
No matter what, shut off as many of the toolbars and other fields at the top of the window as you can. No one will be able to read the Location field, and if your presentation is local, the URLs will be useless anyway. Things like Netscape's Directory Buttons are pointless for the purposes of the presentation, and take up screen space your slides could use to avoid scrolling. Also, many people in your audience may not be able to see the bottom third of the screen, so you'll want your information to be up at the top where everyone can see it. This may seem like a minor point, but you don't want to waste screen space or distract your audience with unnecessary screen controls, and few presenters seem to realize this.
Since no one can see the URLs for the sites you visit, make sure to include them on a handout for the audience. It's a good idea to provide a handout anyway, since that keeps people from madly taking notes when they should be paying attention to what you're saying. For some reason, audiences are always desperate to know exactly what URLs you've visited, and URLs are deucedly hard to convey in spoken words.
I don't want to get into the details of actually making the presentation, other than two quick points. First, if you only have a modem connection, don't apologize for its speed, or, if you must, only apologize once. Second, when you take questions from the audience (which you definitely should do, but only at appropriate breakpoints and again at the end), make sure to repeat the question before answering it. Failing to repeat the question so everyone can hear it before you answer is probably the most common failing of technical presentations.
by Geoff Duncan <geoff@tidbits.com>
In TidBITS-334, we looked at the PowerPC processor family and some of the terms and technologies associated with it. If you read the article, your probably know the difference between 68K and PowerPC chips, why clock speed and clock multipliers are important, the difference between Level 1 and Level 2 caches, and the differences among different PowerPC chips. Part 2 builds on this information and examines additional software and hardware components of the Power Macintosh.
Emulators Forever -- If there's a single thing that made the Power Macintosh successful, it's the 68K emulator built into its system software. Conceptually, the 68K emulator sits between the PowerPC processor and executing code. If code is written for the PowerPC (such code is considered "native"), the emulator does nothing; if the code is written for 68K machines, the emulator translates it to PowerPC code (at a very low level) and passes it to the PowerPC processor. Without a 68K emulator, non-native programs wouldn't run at all on a Power Mac.
The 68K emulator enabled Apple to move the Macintosh to a new processor architecture while retaining strong compatibility with existing programs - undeniably a good thing. At the same time, 68K emulation is also the Achilles heel of the Power Mac because the performance of 68K emulation can't compare to that of native PowerPC code. When the Power Macs were introduced, Power Mac users often took a step backward in performance because the vast majority of Mac software was only available for 68K machines. Though some native applications appeared quickly, major tools like QuarkXPress, Microsoft Office, and FileMaker Pro took a while to become Power Mac-native.
Further, though Apple has ported many critical portions of the system software to take advantage of the PowerPC, much of the system still relies on the 68K emulator. Thus, even high-end Power Macintoshes are caught in a quagmire of 68K code, reducing their potential real-world performance even when running native applications.
If 68K code is so slow, then how long will 68K emulators be around? That's simple: Apple has to keep a 68K emulator in the system forever.
First, the Mac OS relies heavily on the 68K emulator, and though System 8 will contain substantially more Power Mac-native code than System 7.5.3, it's unlikely the entire operating system will ever be fully native. At a basic level, it's not worth the effort to port everything, particularly little-used, non-performance-related portions of the system.
Second, Apple has a vested interest in making sure 68K code and applications continue to run. Almost every Power Mac user owns software written for 68K machines that will never be ported to PowerPC. A good example is Ambrosia Software's arcade classic Maelstrom, which is largely written in 68K assembly language. Porting Maelstrom to the PowerPC would be an enormous undertaking; yet, more than two years after the introduction of the Power Macintosh, Maelstrom continues to run fine in emulation, and is actually a good test of 68K emulators.
<http://www.ambrosiasw.com/Ambrosia_Products/Maelstrom.html>
Keeping 68K emulation in the system doesn't mean that improvements can't be made. Apple's original 68K emulator was static, translating 68K instructions to PowerPC code one at a time. Emulation performance can be improved with larger Level 1 or Level 2 processor caches (emulator performance is better on the PowerPC 603e chip than the original 603 due to a larger Level 1 cache); however, it's also possible to build a smarter emulator.
With the PCI Power Macs, Apple introduced a significantly faster dynamic recompilation (DR) emulator. The DR emulator watches the 68K code for loops and stashes the translated PowerPC code for later use, rather than translating the same 68K instructions over and over again. However, the DR emulator comes with a slightly higher price in terms of compatibility: programs that do not operate correctly on 68040 machines with their processor caches enabled may not run correctly. Also, Apple's DR emulator only works on PCI Power Macs; the ROMs of earlier Power Macs don't support it.
A good alternative is Speed Emulator, part of Connectix's Speed Doubler. (See TidBITS-292.) Speed Emulator is also a DR emulator, and though it uses more memory than Apple's, it also significantly outperforms it and runs on any Power Mac. Speed Emulator's additional performance is particularly obvious in some areas; for instance, it significantly speeds up the Apple Event Manager, a feature particularly appreciated by AppleScript users.
Both Apple's and Connectix's emulators imitate a 68LC040, which is a problem if you need to use a 68K program with a program that specifically requires a floating point unit (FPU). In the 68K family, FPUs were originally a separate chip devoted to floating point math operations. With the 68040, Motorola built most FPU functions directly into the processor, then (in a cost-cutting move) removed them in the 68LC040. Programs requiring an FPU won't run under emulation on a Power Mac because they correctly determine that an FPU isn't available.
If you need to use programs requiring an FPU on a Power Macintosh, you have two choices: SoftwareFPU and PowerFPU, both from John Neil and Associates. These programs emulate a 68K FPU, allowing 68K programs that require an FPU to function. SoftwareFPU, a $10 shareware product, works fine, though it's not PowerPC native and must pump its math calls through the 68K emulator. PowerFPU is a $20 commercial product that provides PowerPC-native FPU emulation. Since native PowerPC floating point functions are speedy, PowerFPU's performance can be quite good.
The Magic Bus -- When evaluating the performance of a computer, most users refer to the machine's processor type and clock speed, primarily because these terms are common, occasionally comparable, and liberally used in marketing materials. However, another major factor in a computer's overall performance is its bus, the main data path between the processor and other components.
The easiest way to explain a bus is by analogy: think of your computer as a small, one-road town. Most of your computer's components live on the road, and the road must be used every time information has to travel between components. A traffic light controls travel, and a complex series of local laws governs who can go ahead, who has to wait, and how often people can get on or off the road. Two things control how fast traffic moves: how many lanes the road has ,and how often the traffic light changes. One thing controls how efficiently traffic moves: local traffic laws.
In this analogy, the bus width is the number of lanes in the road, the bus speed is how often the traffic light changes, and the hardware architecture and operating system are the traffic laws.
Dishing Your Buses -- The analogy above is a vast over-simplification - in reality, a Macintosh has a number of different buses, most of which exist in sub-systems. SCSI, Ethernet, serial ports, RAM, expansion slots (NuBus and PCI), and input devices all have separate buses, each of which has its own width and (sometimes) its own oscillator.
Bus speed is an important factor when considering upgrades. Clock chipping, a popular, inexpensive method for upgrading Quadras and first-generation Power Macs, involves replacing the computer's clock oscillator with a faster one. Although it invalidates Apple's warranty and not all Macs can be clock chipped successfully (success rates are around 90 percent), replacing the clock chip speeds up the computer's processor and bus, often making for a good all-around performance improvement. For detailed information on clock-chipping, check out Marc Schrier's clock chipping FAQ.
<http://violet.berkeley.edu/~schrier/mhz.html>
Many PCI Power Macs and clones have both their clock oscillators and processor chips on a removable CPU daughter card, providing a built-in upgrade path to faster clocks and processors. This design permits you to replace the processor and the clock oscillator at the same time. However, in many cases there's still a limit to how fast the main bus can go. In Apple's current models, the upper limit is 50 MHz; Power Computing's PowerTowers go to 60 MHz. This doesn't mean that daughter card upgrades won't be worthwhile for these machines, but rather that they won't improve the performance of every aspect of the system beyond a certain point.
Similarly, upgrade cards for from vendors like Apple and DayStar for earlier Mac models (from the IIci through the Quadra series) should be evaluated not only on the basis of the promised clock speed of the PowerPC chip, but also in terms of the performance constraints imposed by other hardware. In many cases, these cards must traverse a comparatively slow, narrow bus to get data from disks, ports, other devices, and/or RAM, yielding real-world performance levels considerably lower than Power Macs with equivalent processor speeds. Though these upgrades might be adequate for being able to run PowerPC code, they're rarely equivalent to the performance of a used Power Mac and often cost just as much.
The Myth Of Clock Speed -- In the end, what does all this mean for buying a Macintosh these days?
Be wary of hype surrounding the raw clock speed of a particular machine. Although processor speed is (of course) related to performance - and many computer vendors trumpet little more than the clock speeds of their machines - many other factors (processor type, cache, emulation, bus speed, system software, and more) contribute to a machine's real-world performance.
As an example, Power Macs achieve their high processor speeds by using clock multipliers built into their PowerPC processors, allowing the chips to run faster than the machine's clock oscillator. There's no question this improves performance, but there are limits to how much bang-for-the-buck this technique will produce. There's a real performance difference between a 120 MHz machine using a 6x clock multiplier on 20 MHz bus and a 120 MHz machine using a 2x clock multiplier on a 60 MHz bus. Though both machines would function, the first machine will take much more time to access disks, networks, memory, and peripheral cards than the second machine. Even though they'd be roughly equivalent in terms of raw processor performance, the first machine is going to spend more of its processor cycles waiting for its hardware.
Also, pay attention to what processor a particular machine uses. In terms of raw processor power, a 120 MHz PowerPC 604 is significantly (50 to 75 percent) faster than a 120 MHz PowerPC 601 or 603e, just by the nature of the chip designs. However, in real world terms, a machine with a PowerPC 604 might only mildly outperform a 120 MHz 603e with a fast bus, fast video, fast disks, and a good emulator.
If you can't judge computers by their clock speed, what can you use? Increasingly, the only meaningful measures of real-world performance are produced by benchmark applications like Speedometer, MacBench, and Norton Utilities System Info.
<ftp://mirror.aol.com//pub/info-mac/cfg/speedometer-402.hqx>
<http://www.zdnet.com/zdbop/macbench/macbench.html>
I don't feel the results of these programs can be accepted as gospel. Though tests on my Macs produced results in the right ballpark for each machine, none of these applications produced consistent results in repeated testing. Still, programs like these at least attempt to analyze more than a processor's performance, and if results are sufficiently averaged across a wide range of configurations, they might give a reasonable idea of a machine's real-world performance.
For More Information -- These two articles have covered a lot of territory, and I hope they dispelled some confusion about what different bits of hardware do and how you can relate their specifications to real world performance. If you'd like more information, I'd recommend the following technical sources.
For details on PowerPC processors, look at Motorola's and IBM's information, as well as the PowerPC FAQ:
<http://www.mot.com/SPS/PowerPC/library/library.html>
<http://www.chips.ibm.com/products/ppc/index.html>
<http://www.mot.com/SPS/PowerPC/library/ppc_faq/ppc_faq.html>
If you're interested in how processors are officially benchmarked (and what a SPECint95 means!), check with the source:
Finally, if you're curious about how the PowerPC chip works in the middle of a Macintosh, I recommend this introduction from Apple's Developer University:
<http://dev.info.apple.com/du/intro_to_ppc/ppc0_index.html>
Non-profit, non-commercial publications and Web sites may reprint or link to articles if full credit is given. Others please contact us. We do not guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies.For information on TidBITS: how to subscribe, where to find back issues, and other useful stuff, send email to: <info@tidbits.com>. Otherwise, contact us at: <editors@tidbits.com>.
Back issues are available at these sites via FTP or the Web at:
<ftp://ftp.tidbits.com/pub/tidbits/issues/>
<http://www.tidbits.com/tb-issues/>